前面做到的都是單一 Analysis：

Analysis
→ Run
→ Output

但實際使用時，一份 report 通常不只需要一個分析。

例如 Weekly Report 可能同時需要：

• Events by hour
• Median session length
• Views by category
• Trending videos per month

所以接下來把多個 saved Analysis 組成 Workflow。

Analysis ─┐
Analysis ─┼─→ Batch ─┐
Analysis ─┘          │
                     ├─→ Report
Analysis ─┐          │
Analysis ─┼─→ Batch ─┘
Analysis ─┘

Workflow 本身不重新發明一套 execution。每個 Analysis node 都還是走原本的 saved Analysis runtime，包括 Check、Fetch Inputs、Sandbox Execution、Collect Output 和 Measurements。

Workflow 主要負責三件事：

• 哪些 Analysis 要一起跑
• 同時最多可以跑多少個
• 最後怎麼把 results 收集起來

三種 Node

目前 Workflow 有三種 node：

• Analysis：代表一個 saved Analysis，記錄 analysis_id、datasource mapping 和 position。同一個 Analysis 也可以放兩次，例如分別跑不同 datasource。
• Batch：把幾個 Analysis 的 results 分成一組。Batch 不執行 code，也不代表 execution 順序。
• Report：接一個或多個 Batch，把 results 放在同一個 page 的不同 section。

例如 Weekly Report 可以收集 Events by hour、Median session length、Views by category 和 Trending videos per month，再和另一個 Business Report 一起進到同一個 Combined Report。

Run Workflow

按下 Run 後，所有 connected Analysis 都會先進入 execution queue。

每個 node 的狀態大致會是：

• waiting
• running
• done
• failed
• needs_optimization

拿到 execution slot 才會開始跑；一個 Analysis 結束後，slot 才會讓給下一個 waiting node。

這裡有一點很重要：

Batch 不控制 execution。

不同 Batch 裡的 Analysis 可以同時執行，所以不是先把 Weekly Report 全部跑完，再跑 Business Report。

Parallel，不代表全部一起跑

Workflow 裡可能有 7 個 Analysis，但不代表一次開 7 個 sandbox。

目前一個 account 的 sandbox limit 是 3，所以最多只會同時讓 3 個 Analysis 進入 execution，其餘留在 waiting。

Concurrency 目前受三層限制：

• Workflow 自己的 semaphore
• Sandbox Manager 的 account / global capacity
• Daytona 本身的 quota

Workflow 會先把送進 Sandbox Manager 的數量限制住，避免所有 node 一起去搶 sandbox。

為什麼 Workflow 自己還需要 Queue？

一開始沒有這一層。

最初 implementation 是 7 個 Analysis 同時 request sandbox，但 Sandbox Manager 原本只會等 30 秒。

如果前面的 sandbox startup 比較慢，後面的 node 可能還沒輪到就 timeout。

實際就出現過：

• 7 個 Analysis
• account limit 3
• 只有 6 個完成
• Workflow 最後是 partly_done

問題不是 Analysis 自己失敗，而是大家同時搶有限的 capacity。

所以後來改成 Workflow 自己先 queue：

• 最多只讓 3 個 node 進 Sandbox Manager
• 其他 node 留在 waiting
• 有 slot 釋放才啟動下一個
• Workflow queue 本身沒有 30 秒 timeout

改完後，同樣 7 個 Analysis 就可以全部完成。

每個 Node 還是完整的 Analysis Run

Workflow 並沒有繞過前面做的機制。

如果某個 node 換到比較大的 datasource，Pre-run Check 發現資料量太大，它一樣會變成 needs_optimization。

Optimize 還是回到那個 Analysis 自己的頁面處理。

所以前面做的這些機制都還在：

• datasource swap
• Pre-run Check
• Optimization
• Validation
• Versioning

Workflow 只是把多個 Analysis 放進同一個 orchestration。

Batch 收 Result，不重新跑 Analysis

如果同一個 Analysis node 同時接到兩個 Batch，Analysis 只會跑一次，兩個 Batch 共用同一個 result。

所以 Batch 是 result grouping，不是另一層 execution。

Report 也是組合，不是重新分析

Workflow 跑完後，Report page 才把已經產生的 outputs 組起來。

打開 Report 不會重新：

• query database
• start sandbox
• rerun Analysis

它只是讀取這次 Workflow Run 已經存在的 outputs，再按照 Batch 組成 page。

例如 Weekly Report 可以直接看到：

• Events by hour 跑的是 events_enterprise
• Median Session Length 跑的是 events_enterprise
• 每個 Analysis 使用哪個 version
• execution time
• output chart

另一個 Business Report 則可以放完全不同的 Analysis：

Workflow Run 也要留下自己的 Snapshot

Analysis Run 本身已經有 run history，但 Workflow 還需要記住這次 Run 當時的整體狀態。

目前會保存：

• workflow id / title
• started / finished time
• final status
• 每個 node 的 Analysis
• datasource mapping
• Analysis version
• run id
• status
• Batch mapping
• Report mapping
• concurrency limit

這些都是 run 當下的 snapshot。

所以之後就算 Workflow canvas 被修改，舊 run 還是知道自己當時實際跑的是什麼。

Parallel Execution 的 Cost

這次 demo 一共跑 7 個 Analysis：

• 7 / 7 done
• total time 51s
• peak 3 / 3 sandboxes
• moved 311 rows / 10.1 KB
• script CPU time 7s
• highest peak memory 204 MB

但每個 script 本身其實只跑大約 0.8–1.5 秒。

真正佔掉大部分 workflow time 的反而是：

• waiting for sandbox
• sandbox startup
• moving inputs

而不是 Python calculation 本身。

所以把多個 Analysis 串起來之後，問題開始從 Analysis 能不能執行變成有限的執行資源要怎麼分給很多 Analysis？如果可以的話有辦法自動化嗎？